Les principes de l'Agilité

Cette partie du cours est fortement inspirée par le MOOC Agile de Bertrand Meyer.

Vous trouverez une version actualisée des principes sur Wikipedia :

• https://fr.wikipedia.org/wiki/Manifeste_agile#Les_12_principes
• https://en.wikipedia.org/wiki/Agile_software_development

UK

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

FR

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le projet.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. Privilégiez la co-location de toutes les personnes travaillant ensemble et le dialogue en face à face comme méthode de communication.
7. Un logiciel opérationnel est la principale mesure de progression d’un projet.
8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l’excellence technique et à un bon design.
10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
12. À intervalles réguliers, l’équipe réfléchit aux moyens possibles pour devenir plus efficace. Puis elle s’adapte et modifie son mode de fonctionnement en conséquence.

Du manifesto lui-même :

• Les individus et leurs interactions plus que les processus et les outils
• Du logiciel qui fonctionne plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Du MOOC Agile :

• Nouveau rôle pour le manager (rôle réduit)
• Pas d’étapes trop tôt ou trop importante (longues)
• Développement itératifs (et donc continu)
• Nouvelle façon de négocier (trade off)
• Focus sur la qualité (et donc les tests)

Meetings (suite)

• Retrospective meetings
  • Qu’est-ce qui a marché?
  • Qu’est-ce qui peut être amélioré?
• Review meetings
  • On implique le client

User stories (cards)

User stories vs. UML Use Cases

User stories (ctd.)

Bonne pratique (XP ⇒ INVEST):

• Indépendante des autres histoires d’utilisateur (dans la mesure du possible)
• Négociable (discutée avec l’équipe, notamment lors de l’estimation)
• source de Valeur (porteuse d’une valeur client)

User stories (ctd.)

• Estimable (elle peut être estimée par l’équipe)
• (S)Courte (généralement une ou trois phrases environ)
• D’une Taille appropriée (pouvoir être développée et testée au sein d’une itération)

User stories (suite)

Attributs :

• Un numéro (Id)
• Une importance/priorité client
• Une estimation du coût (en points, temps, …​)
• Une expression de la forme "En tant que …​ je souhaite …​ pour pouvoir …​

User stories (suite)

Story mapping

Une activité populaire consiste à organiser les Stories sous forme d’une matrice et non d’une simple liste : c’est le Story Mapping.

Must, Should, Could, Wont ⇒ MoSCoW

L’autre dimenstion de la matrice :

• par flot (par dépendances entre stories)